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Abstract 


Like  other  U.S.  Department  of  Defense  (DoD)  organizations,  the  U.S.  Air  Force  (USAF)  is 
managing  infonnation,  but  in  a  disjoint  fashion  focused  on  system  and  technical  architectures.  In 
this  paper  we  describe  an  information  architecture  framework  (IAF)  to  guide  the  creation  of 
information  architectures  for  managing  USAF  infonnation  assets  from  an  enterprise  perspective. 
The  IAF  was  generalized  from  common  components  found  within  leading  enterprise  architecture 
frameworks  in  use  today,  adding  fidelity  to  guide  architecture  developers  when  addressing  the 
information  view.  We  show  through  examples  how  infonnation  architecture  elements  fit  into 
IAF  and  relate  it  to  other  USAF  architecture  efforts. 


This  page  intentionally  left  blank. 


Executive  Summary 

Like  other  organizations  within  the  U.S.  Department  of  Defense  (DoD),  the  U.S.  Air  Force 
(USAF)  is  managing  information  right  now,  but  in  a  disjoint  fashion  focused  on  system  and 
technical  architectures.  Migration  to  the  net-centric  vision,  grounded  in  the  principles  of  service- 
oriented  architecture  (SOA)  vice  system  architecture,  has  fundamentally  changed  how  things  get 
done  and  who  are  the  responsible  participants.  In  practice  we  must  address  infonnation  sharing 
challenges,  including  -  but  not  limited  to  -  quality,  consistency,  ownership,  stewardship, 
pedigree,  data  at  rest  and  data  in  flight. 

Now  more  than  ever  the  USAF  needs  an  infonnation  architecture  to  describe  the  information 
assets  it  manages;  this  infonnation  architecture  must  be  constructed  from  an  enterprise 
perspective  to  ensure  ongoing  and  emerging  efforts  are  synchronized  in  a  holistic, 
complementary  fashion.  In  the  context  of  this  paper,  “enterprise”  refers  to  the  USAF,  and 
“information  asset”  refers  to  infonnation  having  value  that  is  both  owned  and  managed.  (It 
should  be  noted  that  we  interpret  the  latter  tenn  differently  from  the  Federal  Enterprise 
Architecture  which  emphasizes  the  physical  aspects  of  managed  assets  and  treats  data  and 
information  assets  interchangeably.) 

Enterprise  Architectures  (EAs)  typically  define  an  agreed  set  of  constructs  that  can  be  used  to 
express  architecture  concepts,  and  a  language  to  communicate  them  to  the  various  enterprise 
stakeholders.  Quite  simply,  an  Enterprise  Infonnation  Architecture  (EIA)  provides  a  means  to 
describe  and  manage  information  consistently  so  it  can  be  accessed,  understood,  compared, 
shared  and  composed  in  a  coordinated,  integrated  manner  across  the  enterprise  at  every 
hierarchical  level. 

From  the  analyst  and  developer’s  perspective,  “framework”  is  used  to  add  a  methodology  and 
categorization  scheme  for  organizing  and  relating  subsets  of  the  architectural  content  relevant  to 
the  infonnation  view  so  that  this  view  can  be  understood  and  manipulated  more  easily.  An 
added  benefit  is  facilitating  the  construction  of  as  much  or  as  little  of  relevant  architectures  as  is 
needed  to  support  strategic  decision-making,  thereby  conserving  limited  resources. 

Thus  we  describe  a  framework  to  guide  the  creation  of  information  architectures  to  support 
managing  USAF  infonnation  assets  from  an  enterprise  perspective:  an  Information  Architecture 
Framework  (IAF).  We  don’t  assign  the  moniker  “Enterprise”  to  this  framework  because  it  is 
intended  for  use  for  any  information  architecture  development  effort  within  the  USAF 
Enterprise. 

The  IAF  we  developed  is  depicted  in  the  figure  below.  It  was  generalized  from  common 
components  found  within  the  information  architecture  view  across  the  leading  EAFs  in  use 
today.  It  also  was  built  to  be  consistent  in  structure  and  content  with  the  AF  Architecture 
Framework  (AF  AF),  extending  it  to  provide  added  fidelity  and  to  guide  architecture  developers 
when  addressing  the  information  view.  In  addition,  this  paper  walks  through  some  examples  to 
relate  specific  information  architecture  elements  to  their  respective  positions  in  the  framework. 
This  serves  as  a  sufficiency  check  on  the  IAF  and  it  also  helps  relate  the  framework  to  other 
USAF  architecture  efforts. 

This  paper  is  a  precursor  to  establishing  an  AF  Infonnation  Architecture  practice.  As  the 
practice  evolves  it  will  be  empirically  proven  in  real-world  use  cases  then  fonnally  documented 
as  practitioners  guidance.  Topics  for  future  exploration  include  the  details  of  the  high-level  IAF, 


the  application  of  the  IAF  in  support  of  a  methodology  for  information  lifecycle  management, 
and  how  the  IAF  supports  fit-for-federation  (guidelines  and  practice  that  support  the  interaction 
of  separate,  but  related  architectures.) 
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1  Introduction 

We  manage  infonnation  because  there  is  value  in  doing  so  and,  just  as  importantly,  undesirable 
consequences  if  we  don’t.  The  value  is  that  information  is  essential  to  minimizing  risk  during 
decision-making  and  to  perfonning  actions.  Like  other  organizations  within  the  U.S. 

Department  of  Defense  (DoD),  the  U.S.  Air  Force  (USAF)  is  managing  infonnation  right  now, 
but  in  a  disjoint  fashion  focused  on  system  and  technical  architectures. 

Migration  to  the  net-centric  vision,  grounded  in  the  principles  of  service-oriented  architecture 
(SOA),  is  fundamentally  changing  how  things  get  done  and  who  are  the  responsible  participants. 
Many  enterprises  mistakenly  believe  that  SOA  will  hide  and  resolve  all  their  infonnation 
management  issues.  In  reality,  SOA  in  practice  elevates  the  need  to  address  the  existing 
challenges  regarding  infonnation  including;  quality,  consistency,  ownership,  stewardship, 
shareability,  data  at  rest,  and  data  in  flight,  to  name  just  a  few. 

Now  more  than  ever  the  USAF  needs  an  infonnation  architecture  to  describe  the  information 
assets  it  manages;  this  infonnation  architecture  must  be  formulated  from  an  enterprise 
perspective  to  ensure  ongoing  and  emerging  efforts  are  synchronized  in  a  holistic, 
complementary  fashion.  This  paper  describes  a  framework  to  guide  the  creation  of  infonnation 
architectures  in  support  of  managing  USAF  information  assets  from  an  enterprise  perspective. 

2  An  IAF  for  the  USAF 

2.1  Background 

Multiple  descriptions  and  definitions  of  enterprise  architecture  (EA)  and  infonnation  architecture 
exist  in  the  literature.  As  discussed  in  Appendix  A,  in  terms  of  EA,  information  architecture 
focuses  in  on  information  assets  and  how  they  relate  to  processes  and  needs.  Incorporating  a 
framework  adds  a  categorization  scheme  to  organize  and  relate  the  content  and  views,  and  also 
enables  an  incremental  development  approach.  Thus,  an  Enterprise  infonnation  architecture 
framework  (IAF)  specifies  how  to  describe  the  design,  planning,  implementation  and  governance 
of  information  architectures  across  the  enterprise.  We  don’t  use  the  “Enterprise”  moniker  in  this 
tenn  because  the  framework  is  intended  for  use  for  any  information  architecture  development 
effort  across  all  levels  of  the  USAF  Enterprise. 

Over  half  of  all  EA  efforts  today  use  one  of  seven  frameworks.  Appendix  B  summarizes  our 
analysis  of  commonalities  shared  across  them  in  terms  of  architecture  perspectives  and 
generalizations  based  on  the  architectural  elements  these  frameworks  treat  in  the  infonnation 
view.  This  material  provides  the  rationale  for  the  infonnation  architecture  framework  (IAF) 
presented  below. 

2.2  A  high-level  view  of  the  IAF 

From  the  common  information  architecture  elements  that  are  addressed  in  the  leading  EAFs,  we 
generalized  the  IAF  proposed  in  Figure  1.  This  framework  was  depicted  in  such  a  way  as  to 
ensure  its  traceability  to  the  AF  Architecture  Framework  (AF  AF),1  extending  it  to  provide  added 


1  AF  Chief  Architect’s  Office.  United  States  Air  Force  Enterprise  Architecture:  Air  Force  Architecture  Framework, 
version  3.0  (TBD) 


fidelity  and  to  guide  architecture  developers  when  addressing  the  information  view.  In  addition, 
Appendix  C  substantiates  that  the  IAF  sufficiently  captures  the  infonnation  architecture  elements 
found  during  our  survey  of  leading  frameworks. 


Uses 

and 

Impacts 


Figure  1.  IAF  --  High-level  view 

In  this  figure  it’s  important  to  note  that  the  IAF  places  a  particular  emphasis  on  information 
assets.  An  asset  is  a  resource  having  value  that  is  both  owned  and  managed.  It  follows  that  an 
information  asset  is  information  having  value  that  is  both  owned  and  managed.2  Since  not  all 
information  has  equal  value,  the  framework’s  focus  is  on  assets  that  are  deemed  to  have 
enterprise  significance  and  that  are  necessary  to  support  the  enterprise  business  strategy  or  to 
achieve  effective  business  change. 

Also  in  this  figure,  “Information  Architecture  Components”  refer  to  groups  of  information 
architecture  elements.  The  framework  describes  information  assets  in  terms  of  three  concepts: 
description,  context  and  sharing. 

2.2.1  Information  asset  description 

“Infonnation  Asset  Description”  covers  structured,  semi-structured,  and  unstructured 
information  assets  that  have  direct  business  value.  Descriptions  involve  defining  both 
information  assets  and  the  relationships  among  them.  In  addition,  descriptions  require  both 
structural  and  semantic  metadata  for  completeness.  Example  artifacts  include  glossaries,  entity 
relationship  models,  subject  categorization  schemes,  and  taxonomies  that  participate  materially 
in  business  operations.  These  artifacts  provide  the  means  to  discover  and  share  information 
consistently  throughout  the  enterprise. 

2.2.2  Information  asset  context 

“Infonnation  Asset  Context”  refers  to  the  non-definitional  accompanying  factors/considerations 
related  to  the  effective  establishment  or  employment  of  an  information  asset.  Examples  include 
stewardship  practice;  characteristics  of  infonnation  quality,  currency,  and  security;  schemes 
describing  the  circumstances  under  which  information  assets  are  deemed  authoritative;  and 


2  It  should  be  noted  that  we  interpret  the  term  “information  asset”  differently  from  the  Federal  Enterprise 
Architecture  [FEA]  Data  Reference  Model,  which  emphasizes  the  physical  aspects  of  managed  assets  and  treats  data 
and  information  assets  interchangeably. 


semantic  descriptive  mechanisms  through  which  an  infonnation  asset  may  be  effectively 
managed  or  employed.3 

2.2.3  Information  asset  sharing 

Finally,  “Infonnation  Asset  Sharing”  is  concerned  with  the  considerations  necessary  for  an 
information  asset  to  be  used  by  consumers  other  than  the  original  producer.  Specifically,  it 
addresses  the  exchange  of  and  access  to  information  assets.  Exchanges  require  infonnation  to  be 
packaged  appropriately.  Exchange  standards  such  as  those  for  result  sets  returned  from  a  text 
search  (including  rank,  synopsis,  and  URL),  Electronic  Data  Interchange  (EDI)  message 
structure,  or  import/export  fonnats  between  applications  are  examples.  Access  considerations 
refer  to  the  infonnation  characteristics  of  the  interface  through  which  access  to  infonnation  is 
achieved.  Examples  include  REST-based  standards  for  constructing  parameterized  URL 
encodings  to  describe  a  search,  Application  Programming  Interface  (API)  or  query  languages 
such  as  SQL-92. 

2.2.4  Information  asset  relationships 

“Infonnation  Asset  Relationships”  refers  to  linkages  between  components  within  the  information 
layer  and  the  three  remaining  layers  (business,  services  and  technology),  as  well  as  relationships 
between  architectural  components  within  the  infonnation  layer  itself.  The  nature  of  these 
relationships  is  described  briefly  in  Tables  1  and  2.  These  tables  suggest  key  questions  the 
information  architecture  descriptions  must  address. 

Table  1  focuses  on  those  questions  related  to  describing  relevant  infonnation  assets  within  the 
information  view,  the  means  for  exchanging  and  sharing  them,  and  how  their  effective 
employment  will  be  accomplished.  Artifacts  examples  are  also  provided. 


Table  1.  Information  Asset  Description,  Sharing  and  Context  Questions 


Description 

Sharing 

Context 

What  are  the  major 

What  are  the  information 

What  supplementary 

information  business  objects, 

sharing  and  access 

information  describes  the 

their  definition  and 

standards  to  be  used  by 

establishment  and  management 

relationships? 

producers  and  consumers? 

of  assets?  Similarly  what 
standards  will  be  used  to 

Artifact  examples:  Business 

Artifact  examples:  MLD- 

describe  characteristics  of  the 

Information 

object  glossary,  entity 

STD  6016, 

asset  in  relationship  to  the  other 

Asset 

relationship  models. 

Blue  Force  Tracking  COI 
schema 

views? 

Artifact  examples:  Asset 
governance  tracking  templates, 
COI  charters,  asset  stewardship 
best  practices,  data  quality 
vocabulary  standards. 

Table  2  takes  a  slightly  different  viewpoint;  its  perspective  is  depicted  in  Figure  2.  This  table 
details  how  the  information  view  relates  to  the  other  enterprise  views  (business,  services  and 

3  Note  that  this  definition  is  somewhat  narrower  that  the  Federal  Enterprise  Architecture  Data  Reference  Model 
definition  of  data  context',  however,  as  detailed  later  under  “Information  asset  relationships,’’  the  lAF’s  explicit 
consideration  of  relationships  between  the  information  layer  and  the  three  remaining  layers  (i.e.,  business,  services, 
technology)  results  in  a  broader  treatment. 


technology)  from  the  perspective  of  an  information  asset,  in  terms  of  description,  sharing  and 
context.  It  suggests  key  questions  the  architecture  descriptions  must  respond  to  in  these 
dimensions  with  respect  to  how  assets  drawn  from  the  information  view  relate  to  others  within 
the  remaining  views.  This  table  also  lists  illustrative  artifact  examples. 


Figure  2.  IAF  -  Perspective  of  Table  2  (inter-view  relationships) 


Table  2.  Inter-view  Relationships,  from  an  Information  Asset  Perspective 


Information 

View 

Relationship  to... 

Information  Asset  Description 

Information  Asset 
Sharing 

Information  Asset 
Context 

Business  View 

How  does  each  asset  map  to  the 
business  processes  to  create  an 
information  flow? 

Artifact  examples:  Asset  to  process 
cross  reference. 

What  are  the  information 
sharing  exchange 
structures  used  in  the 
business  process?  How  do 
the  information  assets  map 
into  these  structures? 

Artifact  examples: 
Information  exchange 
structure  cross  reference  to 
business  processes. 
Information  asset  cross 
reference  to  exchange 
structures. 

Which  assets  are  deemed 
to  be  authoritative  at  each 
point  in  a  business 
process?  What  is  the 
organizational  ownership 
of  assets?  What  asset 
quality  requirements  are 
required  in  each  process? 

Artifact  examples:  Asset 
to  process  cross  reference 
of  attributes. 

Service 

View 

How  does  each  asset  map  to  a  set  of 
services? 

Which  assets  describe  services  to 
support  service  based  operations? 

Artifact  examples:  Asset  to  service 
cross  reference.  UDDI  service 
taxonomy. 

What  exchange  structures 
are  provided  by  each 
service?  What  grammar  is 
used  to  query  a  service? 

How  must  an  information 
asset  be 

mediated/translated  to 
conform  to  a  service? 

How  are  Service  Level 
Agreements  (SLAs) 
described?  Is  there  a 
service  categorization 
scheme?  How  are  query 
access  points  described?  Is 
there  a  vocabulary  to 
describe  data  fidelity  loss 
for  service  interfaces? 

Artifact  examples:  Sharing 
exchange  structure  to 
service  interface  mapping. 
Asset  to  service  interface 
translation  matrix. 

Artifact  examples:  SLA 
Template.  Asset  to  service 
cross  reference  of 
attributes. 

Information 

View 

Relationship  to... 

Information  Asset  Description 

Information  Asset 
Sharing 

Information  Asset 
Context 

How  does  each  asset  map  to  a 

Which  systems  and 

How  is  each  asset 

system  or  location?  Given  the 

technologies  support 

mechanized  and  its 

variety  of  information  assets  and 

transport  between 

characteristics 

associations  with  the  other  views, 

producer  and  consumer 

implemented?  What 

what  technology  constraints  result? 

processes?  What 
technology  requirements 

technologies  or  constraints 
support  this? 

Technology  View 

Artifact  examples:  Requirement  for 

and  constraints  affect 

a  content  management  system  for 
documents.  Inputs  to  a  TV-1. 

implementation? 

Artifact  examples: 

Definition  of  a  mediation 
view  between  physical 
store  and  services. 

Artifact  examples: 

Security  characteristics 
selection  criteria.  Tools 
for  interpreting  business 
rules  (e.g.,  regarding 
authoritative  source 
metadata). 

3  Walk-through  example 

Let’s  walk  through  a  notional  example  to  illustrate  the  application  of  the  IAF  in  terms  of  the 
information  architecture  components  that  underlie  an  operational  data  sharing  solution,  and  how 
they  can  be  related  through  the  IAF. 

In-flight  reporting  by  aircraft  is  part  of  the  process  of  dynamic  situational  awareness.  The 
standard  INFLIGHTREP  message  is  used  to  report  mission  results  and/or  infonnation  of  tactical 
or  intelligence  value.  Reporting  includes  activity  sighted,  sighting  location,  the  aircraft  call  sign, 
the  mission,  and  the  reported  sighting  time. 

Once  again,  we  begin  in  Table  3  by  describing  some  major  information  assets  relevant  to  in¬ 
flight  reporting,  the  means  for  exchanging  and  sharing  them,  and  some  factors  relevant  to  their 
effective  employment.  Then  Table  4  relates  in-flight  reporting  information  assets  (infonnation 
view)  to  assets  within  the  remaining  enterprise  views  (business,  services  and  technology)  in 
terms  of  description,  sharing  and  context. 


Table  3.  Information  Asset  Details  for  In-Flight  Reporting 


Description 

Sharing 

Context 

Information 

Asset 

Major  business  objects 
include  models  for  Aircraft, 
DateTime, 

GeospatialPosition,  Mission, 
and  TextDescription. 

Additionally,  a  battlespace 
event  taxonomy  exists  to 
describe  event  types. 

1.  MLD-STD-6040  (which 
defines  the  INFLIGHTREP) 
is  a  standard  for  information 
sharing. 

2.  The  W3C  XML  Schema 
standard  is  a  used  to  describe 
the  results  from  a  web  service 
call. 

3.  Cursor  on  Target  (CoT)  is 
used  for  sharing  battlespace 
events. 

Vocabularies  are  needed  to 
describe  Geospatial  position 
precision  and  Time  accuracy. 

Tracking  of  data  asset  stewards, 
message  sponsors,  and  message 
configuration  management 
processes  must  be  established. 

Table  4.  Inter-view  Relationships  for  In-Flight  Reporting 


Information 

View 

Relationships 

to... 

Information  Asset 
Description 

Information  Asset  Sharing 

Information  Asset  Context 

Business  View 

The  noted  business  objects 
(Aircraft,  DateTime, 
GeospatialPosition,  Mission, 
TextDescription)  are 
associated  with  the  process  of 
monitoring  the  battlespace  for 
dynamic  events.  These  same 
business  objects  participate  in 
other  processes  as  well  (e.g., 
Target  Execution). 

The  INFLIGHTREP  is 
standard  exchange  structure 
for  sharing  this  information. 

The  asset  mapping  to 
exchange  structure  fields  are: 
Aircraft  maps  to 

Aircraft  Call  Sign;  DateTime 
maps  to  Time_of_Sighting; 
GeospatialPosition  maps  to 
Activity  Location;  Mission 
maps  to  Mission  Number; 
and  TextDescription  maps  to 
Activity. 

Pilots  issuing  INFLIGHTREPs 
are  presumed  to  provide 
authoritative  data  for  all  fields. 

The  C2  Node  (e.g.,  AW  ACS, 
CAOC)  is  the  organizational 
owner  of  the  operational 
information  assets. 

The  USAF  GCIC/RIN  is 
sponsor  of  the  INFLIGHTREP 
message.  The  USMTF  CCB  is 
the  configuration  manager  of 
MIL-STD-6040. 

DateTime  must  be  accurate  to 
the  nearest  second.  Geospatial 
position  must  be  accurate,  at 
minimum,  to  the  nearest 
LAT/LONG  minute. 

Sen’ice 

View 

These  assets  map  into  a 
variety  of  services. 

Voice  formatted  in  flight 
reports  (INFLIGHTREPs)  are 
manually  processed  for  data 
entry. 

The  battlespace  awareness 
service  provides  publication 
and  subscription  services  for 
basttlespace  events. 

Service  (1)  records  voice 
formatted 

INFLIGHTREPs  to  an 
internal  DB. 

Service  (2)  produces  CoT 
messages. 

Subscriptions  are  established 
using  the  CoT  vocabulary. 

Translation  tables  record  the 
mappings  between  the  fields 
of  an  INFLIGHTREP  and  the 
internal  DB  as  well  as  from 
the  internal  DB  to  the  CoT 
message  structure. 

Service  (1)  is  categorized  using 
the  term  MANUAL  DATA 
ENTRY  and  Service  (2)  is 
categorized  using  the  term 
AUTOMATED. 

A  data  fidelity  propagation 
table  tracks  transmit  to  retrieve 
data  loss  across  service 
interfaces. 

Service  2  uses  SLA  template 
SLA-89-C. 

Technology 

View 

INFLIGHTREPs  are 
produced  by  the  pilot  to  be 
sent  via  RF  communications. 

INFLIGHTREPs  stored  in 

DBs  require  relational 
database  technology  to 
implement  the  information 
asset  physical  data  models. 

INFLIGHTREPs  are  sent  via 

RF  (e.g.  HAVEQUICK  radio) 
and  manually  transferred  to 
networked  storage  for 
network  sharing. 

A  CoT  routing  capability  is 
required  to  deliver  CoT 
messages  to  subscribers. 

INFLIGHTREP  is  secret 
NOFORN  and  security  is 
provided  via  encryption 
protocols. 

Tools  for  profiling  and  tracking 
data  quality  of  services  are 
required. 

Configuration  management 
tools  for  managing  exchange 
standards  are  required. 

4  USAF IAF  related  to  other  efforts 

As  stated  earlier,  the  IAF  was  built  to  be  consistent  in  structure  and  content  to  the  AF  AF. 
Additionally,  the  IAF  is  complementary  to  established  EAFs.  The  IAF  fills  gaps  in  the 
information  view  at  a  level  of  detail  beyond  what  other  EAFs  typically  capture.  For  example, 
unlike  the  Federal  Enterprise  Architecture’s  emphasis  on  the  physical  aspects  of  managed  assets, 
the  IAF  addresses  the  conceptual  and  logical  as  well  as  the  physical  dimensions  of  information. 
Pursuant  to  the  net-centric  data  strategy,  through  the  establishment  of  communities  of  interest, 
DoD  has  initiated  many  near-term  efforts  to  expose  the  necessary  properties  of  information 
assets,  such  as  taxonomies,  ontologies  and  related  models.  The  IAF  supports  recognizing  the 
relative  contributions  of  these  efforts  to  the  totality  of  architecture  elements  and  products 
required  to  flesh  out  the  information  layer. 

5  Summary  and  way-ahead 

This  paper  discusses  the  role  of  information  architecture  to  ensure  that  USAF  infonnation  is 
described  consistently,  so  it  can  be  accessed,  understood,  compared,  shared  and  composed  in  a 
coordinated,  integrated  manner  across  the  Enterprise.  It  describes  an  Information  Architecture 
Framework  (IAF)  in  support  of  managing  USAF  information  from  an  enterprise  perspective. 

This  framework  is  intended  for  use  for  any  information  architecture  development  effort  within 
the  USAF  Enterprise. 

The  incorporation  of  a  framework  adds  a  classification  scheme  for  organizing  and  relating 
subsets  of  the  architecture  content  relevant  to  the  infonnation  view.  In  addition,  a  framework 
enables  the  application  of  an  incremental  development  approach  to  architecture  descriptions  in  a 
coordinated  fashion,  leading  to  a  consistent,  integrated  whole.  An  added  benefit  is  facilitating 
the  construction  of  as  much  or  as  little  of  relevant  architectures  as  is  needed  to  support  strategic 
decision-making,  thereby  conserving  limited  resources. 

We  surveyed  the  information  perspective  of  several  leading  EAFs  to  derive  some  generalizations 
of  the  architectural  elements  that  they  associate  with  the  infonnation  view.  We  used  that 
analysis  to  establish  sufficiency  of  coverage  for  the  framework  described  in  this  paper.  We  also 
looked  at  an  operational  data  sharing  example  to  illustrate  application  of  the  IAF.  These 
analyses  served  to  confirm  the  IAF  provides  a  foundation  that  captures  the  architecture  elements 
needed  in  practice,  and  they  helped  relate  the  IAF  to  other  USAF  and  DoD  architecture  efforts. 

This  paper  is  a  precursor  to  establishing  an  AF  Infonnation  Architecture  practice.  As  the 
practice  evolves  it  will  be  empirically  proven  in  real-world  use  cases  then  fonnally  documented 
as  practitioners  guidance.  Topics  for  future  exploration  include  the  details  of  the  high-level  IAF, 
the  application  of  the  IAF  in  support  of  a  methodology  for  information  lifecycle  management, 
and  how  the  IAF  supports  fit-for-federation  (i.e.,  guidelines  and  practice  that  support  the 
interaction  of  separate,  but  related,  architectures.) 


Appendix  A  Architecture  from  an  enterprise  perspective 

A.l  Architecture  from  an  enterprise  perspective 

A  good  working  definition  of  “enterprise”  is  any  organization  or  group  of  organizations  that  has  a 
common  set  of  goals  or  principles  or  a  single  “bottom  line.”  For  example,  an  enterprise  can  be  a 
corporation,  a  single  department,  a  government  entity,  or  a  network  of  geographically  remote 
organizations.  In  this  paper,  the  “enterprise”  we  refer  to  is  the  USAF. 

Because  enterprises  tend  to  be  large  and  complex,  the  discipline  of  Enterprise  Architecture  (EA)  is 
broad  and  multi-faceted.  Its  ultimate  purpose  is  to  infonn,  guide  and  constrain  strategic  decision¬ 
making  for  the  enterprise,  for  example  business  operations  efficiency  or  selecting  infonnation 
technology  investments. 

To  deal  with  this  scale  and  complexity,  EAs  typically  define  an  agreed  set  of  constructs  that  can  be 
used  to  express  architecture  concepts,  and  a  language  to  communicate  them.  As  illustrated  in 
Figure  A-l,  most  EAs  include  complementary  projections  of  their  content  called  views  (e.g., 
business,  information,  services,  technology),  where  each  view  culls  out  those  subsets  of  the  total 
architecture  content  that  are  meaningful  to  various  groups  of  stakeholders. 
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Figure  A-l.  EA  Views 

A.2  Information  architecture  from  an  enterprise  perspective 

As  with  EA,  multiple  descriptions  of  information  architecture  exist  in  the  literature,  each  with  their 
respective  proponents.  These  range  from  very  narrow  to  all-encompassing.  Whether  focused 
generically  on  information  sharing  environments  or  specifically  on  intranets  or  online  communities, 
most  information  architecture  definitions  converge  on  the  attributes,  structures  and 
interrelationships  among  data  and  infonnation  assets.  In  terms  of  EA,  information  architecture 
focuses  in  on  information  assets  and  how  they  relate  to  processes  and  needs.  Information 
architecture  specifies  principles,  technologies  and  models  which  link  the  information  view  to  the 
business,  services  and  technology  views  of  the  architecture.  For  example,  infonnation  architecture 
provides  policies  and  rules  for  designing  and  implementing  effective  information  sharing  services. 

Enterprise  information  architecture  (EIA)  is  distinct  from  information  architecture  in  the  following 
ways.  It: 

•  addresses  the  entire  lifecycle  of  information. 

•  focuses  on  semantic  infrastructure  versus  project-specific  details  (to  enable  broader  horizontal 
integration). 

•  supports  delivering  integrated  capabilities  and  information  across  the  enterprise  with  reduced 
complexity. 


In  short,  EIA  ensures  that  information  is  being  described  consistently  so  it  can  be  managed, 
accessed,  understood,  compared,  shared  and  composed  in  a  coordinated,  integrated  manner  across 
the  enterprise. 

A.3  The  value  added  by  framework 

An  EA  Framework  (EAF)  incorporates  a  categorization  scheme  used  to  organize  and  relate  the 
content  and  views  associated  with  EAs.  Categorization  is  used  in  many  disciplines  to  bin  like 
things  into  groups  so  that  they  can  be  understood  and  manipulated  more  easily.  Typical  architecture 
frameworks  address  how  architecture  content  is  organized  both  in  terms  of  structures  and 
hierarchies.  In  terms  of  views  or  products,  the  framework  may  address  which  stakeholders  use 
them  and  in  what  circumstances. 

In  addition,  a  framework  enables  the  application  of  an  incremental  development  approach  to 
architecture  descriptions  in  a  coordinated  fashion,  leading  to  a  consistent,  integrated  whole.  An 
added  benefit  is  facilitating  the  construction  of  as  much  or  as  little  of  relevant  architectures  as  is 
needed  to  support  strategic  decision-making,  thereby  conserving  limited  resources. 

Effective  EAFs  share  a  number  of  characteristics,  among  them: 

•  A  top-down  approach  that  fosters  an  architecture  driven  out  of  the  business  strategy. 

•  Support  for  abstraction  that  allows  complex  details  to  be  “factored  out.”  For  example, 
descriptions  might  be  supported  in  multiple  levels,  progressing  from  less  to  more  extensive, 
specialized  details  at  subsequent  level. 

•  A  robust  set  of  organizing  principles  and  a  well-developed  language  for  communicating  them. 

•  An  associated  process  or  methodology  for  instantiating  an  EA  from  the  framework. 

•  Advice  on  governance. 

An  Infonnation  Architecture  Framework  (IAF)  also  is  a  categorization  scheme,  but  its  focus  is  on 
organizing  and  relating  the  content  associated  with  the  information  view  of  an  architecture. 
Typically,  an  IAF: 

•  provides  a  methodology  for  describing  infonnation  assets. 

•  shows  how  the  architecture  components  (building  blocks)  intenelate. 

•  establishes  a  common  vocabulary  for  describing  infonnation  architecture  products. 

•  recommends  relevant  products  for  documenting  infonnation  architecture. 

So,  an  Enterprise  IAF  specifies  how  to  describe  the  design,  planning,  implementation  and 
governance  of  information  architectures  across  the  enterprise.  We  don’t  use  the  “Enterprise” 
moniker  in  this  term  because  the  framework  is  intended  for  use  for  any  infonnation  architecture 
development  effort  across  all  levels  of  the  USAF  Enterprise. 


Appendix  B  Survey  of  current  EA  practice 


Over  half  of  all  EA  efforts  today  use  one  of  the  following  seven  frameworks: 

•  Zachman 

•  Department  of  Defense  Architecture  Framework  (DoDAF) 

•  Extended  Enterprise  Architecture  Framework  (E2AF) 

•  Computer  Integrated  Manufacturing  Open  Systems  Architecture  (CIMOSA) 

•  The  Open  Group  Architecture  Framework  (TOGAF) 

•  Federal  Enterprise  Architecture  Framework  (FEAF)4 

•  Gartner.5 

Taken  as  a  whole,  these  EAFs  exhibit  many  differences  in  specific  details  such  as  evolutions, 
purpose,  scope,  principles,  structures  and  approaches;  however,  there  are  some  common  themes 
across  them.  For  example,  each  framework  can  be  characterized  in  terms  of: 

•  type  /  orientation  (e.g.,  framework,  process,  reference  model); 

•  categorization  /  focus  (e.g.,  activities  and  flow,  collaboration,  components,  methodology, 
change); 

•  planning  /  use:  (e.g.,  products,  communication,  process,  planning,  implementation). 

It’s  also  possible  to  derive  some  generalizations  based  on  the  architectural  elements  these 
frameworks  treat  in  the  information  view.  We  evaluated  the  infonnation  architecture  aspects  of 
the  surveyed  EAFs.  Our  analysis  identified  commonalities  shared  across  the  EAFs.  These  are 
grouped  in  Table  B-l  together  with  representative  examples. 


Table  B-l.  Grouped  Information  Architecture  elements,  with  examples 


Framework 

Views 

-context 

-conceptual 

-logical 

-physical 

Methodology 

Categorization 

Reference 

Activities/process 

Drivers  (input) 

Requirements 

Strategy 

Standards 
[meta-]  Models 
Principles 

Integration 

Classification 

Design 

Sharing 

Query 

Interface 

Vocabulary 

Value 

Interoperability 

Rules 

Exchange  format 

Management 

Governance 

Ownership 

Stewardship 

Policy 

Politics 

Organization 

4  Key  details  about  the  first  six  EAFs  are  summarized  in  Schekkerman,  Jaap.  How  to  survive  in  the  jungle  of 
Enterprise  Architecture  Frameworks.  Victoria,  BC:  Trafford  Publishing,  2004. 

5  Details  about  Gartner’s  EAF  can  be  found  in  the  article  Gartner’s  Enterprise  Architecture  Process  and  Framework 
Helps  Meet  21st  Century  Challenges,  Retrieved  September  24,  2008,  from 
http://www.gartner.com/it/products/research/asset  129493  2395.isp 


Classification 


Representation 

Syntax 

Semantics 

Relations  /  properties 
Taxonomy 
Definition 
Format 

Quality  /  attribute 
Pedigree 

Security _ 


Physical  /  Resource 

Asset 

Repository 

Stores 

Database 

Webpage 

Producer 

Consumer 

Asset  location 
Network 

Uses  / Impact  (output) 

Employment 

Gaps 

Change 

Appendix  C  Acronyms 


AF  AF 

API 

CDM 

CIMOSA 

DoDAF 

E2AF 

EA 

EDI 

EIA 

FEA  DRM 

FEAF 

IAF 

REST 

SOA 

SQL 

TOGAF 

USAF 

URL 


Air  Force  Architecture  Framework 
Application  Programming  Interface 
conceptual  data  model 

Computer  Integrated  Manufacturing  Open  Systems  Architecture 

Department  of  Defense  Architecture  Framework 

Extended  Enterprise  Architecture  Framework 

Enterprise  Architecture 

Electronic  Data  Interchange 

enterprise  infonnation  architecture 

Federal  Enterprise  Architecture  Data  Reference  Model 

Federal  Enterprise  Architecture  Framework 

Infonnation  architecture  framework 

Representational  State  Transfer 

service-oriented  architecture 

Standard  Query  Language 

The  Open  Group  Architecture  Framework 

United  States  Air  Force 

Uniform  Resource  Locator 


